About

The original data, posted by Kaggle user MÖBIUS, can be found here:

• https://www.kaggle.com/datasets/arashnic/fitbit

The information itself was generated by respondents to a distributed survey via Amazon Mechanical Turk from the days of March 12, 2016 to May 12, 2016. Thirty-three eligible Fitbit users consented to the submission of personal tracker data, involving up to minute-level output for physical activity, heart rate, and sleep monitoring. This information was then fitted to the features present in this data set, including classifications like that of activity intensity, measurements like that of calories burned, and up to minute level observations of variables such as sleep status and heart rate.

Drawbacks

The data is marvelously detailed and dense, but the sample size and duration of record might be too small to consider for confident data-driven decision making. In addition, Bellabeat markets directly to women, and this data does not classify by gender since it is anonymous.

However, what this information lacks in sample size and target demographic, it makes up for in sheer detail. These types of data sets that describe a snapshot of target behavior can be helpful in discerning outstanding or significant trends to inspect further using more widespread and comprehensive data if such can be found.

Some Remedies

Luckily, a short Kaggle search reveals another data set, posted by Kaggle user Akash Kumar, that seems to include similar data regarding a number of Fitbit Users from March 11, 2016 to April 11, 2016, which I noted was suspiciously adjacent to the study the original data set was built from (which took place from April 12 to May 12 of the same year). Upon further inspection (extrapolated on under the (italics) Prepare header), I found that all the users were the same, and this is essentially a precursor data set to the one from April to May. This gives us some more time context to work with, which will further reinforce our analysis.

The Tables

Preparing Daily Sleep, Daily Activity, and Weight Log

Since our questions are comprehensive, it might prove beneficial to start with just the first few data sets, and work our way down as needed, for peace of mind and memory. This will also help us stay organized in our search - I’ve found that it can be frustratingly easy to forget which table you’re working with and accidentally change something you shouldn’t have. This is only slightly harder than overlooking said issue until it ruins your calculations and you need to take a 10-minute walk before seeing any code again.

Let’s begin with our daily activity, weight log, and daily sleep tables. We will highlight the preparatory process for these three in this section, but the prepare task is one which should be completed for each data set used for analysis. We will encounter that too, but on an as-needed basis so as not to clutter our code.

I’ll be using R, with the help of readr and tidyverse to get a quick look at our information

## Imports
library(readr)
library(tidyverse)

## Read in data 
daily_act <- read_csv('fitbit/dailyActivity_merged.csv')
daily_sleep <- read_csv('fitbit/sleepDay_merged.csv')
weight_log <- read_csv('fitbit/weightLogInfo_merged.csv')

# daily activity
daily_act %>% head(3) %>% knitr::kable() 

# daily sleep
daily_sleep %>% head(3) %>% knitr::kable()

# weight log
weight_log %>% head(3) %>% knitr::kable() 

paste("Users in daily activity : ",n_distinct(daily_act$Id))

paste("Users in daily sleep : ",n_distinct(daily_sleep$Id))

paste("Users in weight log : ",n_distinct(weight_log$Id))

## checking common values between user ID in daily sleep and daily act

act_id <- unique(daily_act$Id) # daily act unique ID's
sleep_id <- unique(daily_sleep$Id) # daily sleep unique ID's

paste("Number of common values: ",length(intersect(act_id, sleep_id)))

## [1] "Number of common values:  24"

## Daily Activity ###############################################################
paste0("Total Nulls : ",sum(is.na(daily_act)))

paste0("Total Duplicates : ",sum(duplicated(daily_act)))

## Daily Sleep ##################################################################
paste0("Total Nulls : ",sum(is.na(daily_act)))

paste0("Total Duplicates : ",sum(duplicated(daily_act)))

Second Fitbit Data Set

The other data set we have yet to look at is the supplementary CSV file from Anish Kumar that completes the two month arc from March 11 to May 12, 2016.

second_fitbit <- read_csv('second_fitbit_data.csv')
second_fitbit %>% head(3) %>% knitr::kable() # glimpse of data

paste("nulls : ",sum(is.na(second_fitbit)))

[1] “nulls : 0”

paste("duplicates : ",sum(duplicated(second_fitbit)))

[1] “duplicates : 0”

Now, for the moment of truth…

## Checking if this data set's users overlap with those of daily act and daily sleep

secfit_id <- unique(second_fitbit$Id)
paste("number of ID's in second_fitbit: ", length(secfit_id))

[1] “number of ID’s in second_fitbit: 35”

paste("Number of shared values: ", length(intersect(act_id, secfit_id))) ## used act_id from before

[1] “Number of shared values: 33”

They have as much overlap as possible! We’ll be able to merge this with our daily activity table, but not daily sleep. This data set will be a useful tool for when we want to inspect activity individually over a longer scale of time.

Individual Inspection and Cleaning

Like the Prepare step, this step should be performed every time a data set is loaded up. Processing is an umbrella term for checking and cleaning information in a table. We already know every cell is filled and there are no duplicates, so the content is sufficiently prepped for analysis. Now comes the time to transform the data into something more easily understood by R.

This will consist of a few procedures:

• Transform the date and datetime columns into something more mutable using lubridate
• Get rid of unneeded columns
• Standardize column names

Luckily, we can do all of this in one process using the %>% operator and help from dplyr and janitor.

library(lubridate)
library(janitor) ## for clean_names() --> makes all spaces underscores, caps lowercase

### Daily Activity ******************************

daily_act <- daily_act %>% 
  mutate(date = mdy(ActivityDate)) %>% 
  select(-ActivityDate) %>% 
  clean_names() ## create a datetime object called date, delete original date column, clean names

daily_act %>% head(3) %>% knitr::kable()

### Daily Sleep *********************************

daily_sleep <- daily_sleep %>% 
  mutate(date = mdy_hms(SleepDay)) %>% 
  select(-SleepDay) %>%
  clean_names() 

daily_sleep %>% head(3) %>% knitr::kable()

### Second Fitbit *******************************

second_fitbit <- second_fitbit %>%
  mutate(date = mdy(ActivityDate)) %>%
  select(-ActivityDate) %>% 
  clean_names()

second_fitbit %>% head(3) %>% knitr::kable()

Merge

We’ll create two new data sets for further inspection. The first one will be daily act and daily sleep merged, and the other will be a concatenation of both activity data sets.

Speaking of which….(see code: )

## I should probably rename this to something more descriptive

mar_to_apr_act <- second_fitbit

act_sleep <- inner_join(daily_act, daily_sleep, by=c("id","date"))
paste0("Total number of ID's : ",n_distinct(act_sleep$id))

## [1] "Total number of ID's : 24"

act_sleep %>% head(3) %>% knitr::kable()

paste0("Where is the date column currently located: at column ",grep('date', colnames(act_sleep)))

## reordering
act_sleep <- act_sleep[,c(1,15,3,4,5,6,7,8,9,10,11,12,13,14,2,16,17,18)]
act_sleep %>% head(3) %>% knitr::kable()

act_extended <- rbind(mar_to_apr_act, daily_act)
act_extended %>% head(3) %>% knitr::kable()

## Data types present 
sapply(act_sleep, class)

Revisiting our big picture questions

As we approach our strategy for analysis, it would be beneficial to revisit the big picture questions we laid down in the Ask phase. With a little more context from our data sets, we can break these holistic questions down into more targeted queries.

• What are the general trends of activity, both physical and interactive, exhibited by wearable health tech consumers?
  • What is the distribution of frequency of fitbit use? Total number of days logged per user?
  • Are there certain times of the week or the day that users are most active?
  • What is the general difference between time spent in bed and time spent asleep?
• How do consumers measure up to recommended health standards, and each other?
  • What is the recommended amount of sleep for adults, and are users meeting it?
  • What is the recommended amount of steps taken for adults, and are users meeting it?
  • Is there any distinct stratification between users on the bases of one of the variables? Are people spread out in the distribution, or are there clear levels?
• Are there any features that suggest insightful relationships, and are these indicative of something Bellabeat can exploit in its marketing strategy?
  • If lacking in sufficient sleep, can we correlate the gap to another feature? (i.e. total steps)
  • How strong of a trend is there between calories burned, total intensity, etc.?

General Activity Trends per User

We’ll begin by getting to know our users a little.

Let’s start by seeing if we can find a way to quantify their time spent using the fitbit. We’ll do this sorting act_sleep users by total number of days used, and storing the result in days_used.

Next, to create a categorical variable, we’ll sort users based on the total number of days of activity, breaking our (in this case) 31 day stretch into 3 pieces.

• casual : 0 - 6 days
• moderate : 7 - 15 days
• frequent : 16 - 22 days
• active : more than 22 days

## Create a new DF with new categorical variable

days_used <- act_sleep %>% 
  group_by(id) %>%
  summarize(days_used = n()) %>% 
  mutate(user_type = case_when(
    days_used < 7 ~ "casual",
    days_used < 16 ~ "moderate",
    days_used < 23 ~ "frequent",
    days_used < 33 ~ "active"
  ))

## Take a look

days_used %>% 
  group_by(user_type) %>%
  summarize(amount = n()) %>%
  mutate(percent_of_whole = (amount/24)*100) %>%
  knitr::kable()

We’ll then manipulate these data sets to gain some insight into our variables.

Final Conclusions and Business Ideas

Wearable health technology seems to either stick completely, or never catch on with someone. The question of reliable use is binary - the majority of users either make it part of their routine or lose momentum with the device quickly. Those that do use it more frequently tend to burn more calories, and are more likely to get the recommended amount of steps and sleep in per day.

This is proven evidence that marketing can use as a fact for advertising their wearable health technology. Wearing their technology increases the chances that the wearer will see a healthy lifestyle change if they stick with it.

Fitbit use is most prevalent on the weekends for casual users with peaks and valleys in between, whereas for active users, daily fitbit use is much more sustained throughout the week, with Monday-Thursday being a sustained peak.

There seems to be a dip in productivity near the middle of the week for active users. In addition, active users spend the most time in bed awake on Sunday. Maybe the app can feature a mid-week stress-relief meditation track, along with a restless night meditation track, or even partner with a health meditation app like HeadSpace to do so. This could have a positive effect on user’s productivity and total minutes asleep when compared to total minutes in bed.

Afterthoughts

Though this data is insightful, to find more sustained evidence I’d want to run significance tests on this. The sample size was pretty small, and this did only account for six weeks. I had a lot of trouble looking at minute-to-minute intensities, and I don’t think I’m yet quite skilled enough to glean substantial information from it that isn’t redundant with insights from other tables. The business objective asks for macro-level approaches to marketing and feature inclusion, so I felt like it wasn’t all that important.

If I had superpowers, I’d like to chart minute-to-minute intensities of active users vs non-active users and cross reference them with mean total steps or calories burned to understand the effect step count has on intensity.

Another thing I’d have liked to do would be to use bootstrapping techniques to resample each group to get a more normalized mean distribution. That way I can be more sure whether differences between the different groups of users are statistically significant or not.

All in all, this was a fun project and it definitely laid the groundwork for my approach to exploratory data analyses in the future.